The TypeScript Workshop by Ben Grynhaus Jordan Hudgens Rayon Hunte Matt Morgan and Wekoslav Stefanovski

Author:Ben Grynhaus, Jordan Hudgens, Rayon Hunte, Matt Morgan, and Wekoslav Stefanovski
Language: eng
Format: mobi
Publisher: Packt Publishing Pvt. Ltd.
Published: 2021-07-27T16:00:00+00:00

Figure 8.4: The output from running the app

We won't dive into Angular's template engine or change detection mechanisms – those are two big topics in themselves – but you can refer to the Angular documentation for more information on that. Instead, let's focus on what's going on with regard to DI – notice that we asked for a UsersService object in the UsersListComponents constructor; we didn't specify that we wanted to get a specific instance of the service and so on, just that we want one. This is very powerful, since this offloads the logic of how and where this service is instantiated to a dedicated place (the NgModule) and opens up a lot of possibilities. We could test the component more easily (by providing a fake UsersService), or even just replace the UsersService implementation at runtime with another one.

Angular providers can also require other providers; for example, we could have a generic HTTP client service that knows how to make HTTP calls, and then inject that into our UsersService, which can focus on more high-level details such as the endpoint, which it needs to use in order to fetch the users. In fact, Angular has such an HTTP service built in, called HttpClient. You can use it and fix the mock implementation we had for the users with a real one, utilizing DI further as shown here:

import { Injectable } from '@angular/core';

import { HttpClient } from '@angular/common/http';

import { Observable } from 'rxjs';

export interface User {

name: string;

}

@Injectable()

export class UsersService {

constructor(private httpClient: HttpClient) {}

getUsers(): Observable<User[]> {

return this.httpClient.get<User[]>('/api/users');

}

}

Here, we ask for an HttpClient and use its get() method to make a GET request to the /api/users endpoint in our site, which should return an array of User objects – that is, objects with a property called name, with a string type.

This replaces the mock implementation we had earlier with a more real-world use case by calling an external endpoint instead of returning a static list of users.

Again, notice that we just asked for an HttpClient interface again. We don't care about how it's implemented (this could involve using XMLHttpRequest, fetch, or even another underlying library), as long as it conforms to the HttpClient interface.

You may have noticed that the path that we request from HttpClient is a relative one. This works if our backend is on the same domain as our frontend (for example, https://example.com is our website and https://example.com/api/users would return the users). However, if we want to move our backend to a different server, this will break our website. In the next exercise, we will fix this, using Angular's DI mechanism and by adding HttpInterceptor.

HttpInterceptor is an interface Angular provides that we can implement in order to "hook," or even change network requests, either on their way out (the request), or on their way back (the response), before any other consumer "sees" the response. This will work wherever HttpClient is used in the application, without requiring any more code modifications in other services that use HttpClient.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.